1. Field
Embodiments of the present invention generally relate to computer networking. In particular, embodiments of the present invention relate to achieving security and/or flexibility in networking systems by maintaining security parameters for security devices in the cloud to facilitate dynamic creation of appropriate security policies on peer security devices in support of desired security services, for example.
2. Description of the Related Art
Computer networks used by large business enterprises generally consist of a network of networks spread over geographical regions ranging from different buildings to different continents. Each individual network may contain various network appliances such as routers, switches, gateways, firewalls, Wireless Access Points, and can also be considered to include general purpose computing devices such as personal computers, personal digital assistants (PDAs), laptops, printers, among others. Network appliances typically provide ability for electronic devices to communicate and exchange content/information with other remote electronic devices that are spread over geographical regions.
Enterprise customers are now demanding cost-effective, outsourced connectivity and security services, such as Virtual Private Networks (VPNs). A VPN is a private network that takes advantage of public telecommunications (e.g., the Internet) and maintains privacy through use of tunneling protocols and security procedures.
Current VPN setup procedures are complicated, requiring network administrators to perform extensive manual configurations on both peers of the VPN connection before the VPN can be used. For example, if an Internet Protocol Security Protocol (IPSec) VPN needs to be setup between a headquarters network (HQ) and a branch office network, the HQ security device (e.g., a firewall) usually needs to have created therein a firewall address object for the local subnet and a firewall address object for the remote branch subnet. The HQ security device also needs to create an IPSec VPN phase1 object. Creation of the phase1 object typically requires manual input of numerous parameters, such as a remote gateway IP address, a local interface, a VPN mode, a VPN authentication method, a pre-shared key etc. The HQ security device must also create an IPSec VPN phase2 object, which requires manual input of further parameters. Next, the network administrator must creates a firewall policy within the HQ security device using the address objects, the phase1 and phase2 objects and additional parameters. A corresponding procedure must be performed for the branch office security device. The parameters, such as remote gateway IP address, remote subnet and pre-shared key are usually shared by the network administrators of the HQ and branch office networks offline.
The procedure to configure a VPN can be complicated and fallible because many parameters are involved and shared. When communications are needed among multiple sites, VPN configuration procedures are more complicated. For example, if a company has N sites and each site requires manual configuration of 4 firewall objects (2 firewall address objects, and 2 IPSec VPN objects (i.e., phase1 and phase2 objects)) and 1 firewall policy on each firewall for each site-to-site VPN connection, the administrators are required to configure 5×N×(N−1) objects in total for the N-site VPN.
Further, maintenance of all the VPN configurations is also complicated. If either remote gateway IP address or subnet of one of the participating sites is changed, configurations of all related peers that have connections to the changed site have to be manually adjusted in order to maintain full connectivity among the participating sites.
Some technologies seek to address various aspects of the above-illustrated complexities, but they represent only partial solutions. For example, if a peer's firewall IP address is dynamically assigned by a Dynamic Host Configuration Protocol (DHCP) server, a Fully Qualified Domain Name (FQDN) can be used, instead of using its IP address. However, this solution still requires the network administrator to know the peer's FQDN first, and an additional Domain Name System (DNS) entry is needed for this in the DNS server.
If the remote subnets are changed, it is possible to use routing protocols instead of obtaining information regarding the remote subnets offline. But, for routing within private networks, routing protocols have to be run on top of the IPSec VPN tunnels, which in turn require these tunnels to be configured and setup manually in advance. Furthermore, this approach requires the network administrators to have additional knowledge regarding the configuration of routing protocols.
In view of the foregoing, there exists a need for methods and systems that automate one or more aspects of security device parameter configuration and/or creation of appropriate security policies on peer security devices to facilitate more efficient establishment of desired security services.